As we are already updating widget/cocoa/*.h

Ehsan, what do you think?

That is fine with me, but I'd like to get a second opinion from Markus too.

I'd love to see automated formatting of .mm files! Could you attach a formatted nsChildView.mm or nsNativeThemeCocoa.mm so that we can take a look at how clang-format deals with Objective C code?

Markus: voila: https://github.com/sylvestre/gecko-dev/commit/b5c5ca43ddd5a3f735cb5bb38b772385b7e92a9f

Thanks! Looks good to me.
Most importantly, multi-line objective C method invocations are aligned at the colons and nested invocations look fine, too:

    [[[NSWorkspace sharedWorkspace] notificationCenter]
        addObserver:self
           selector:@selector(systemMetricsChanged)
               name:NSWorkspaceAccessibilityDisplayOptionsDidChangeNotification
             object:nil];

    [[NSBezierPath bezierPathWithRoundedRect:rect
                                     xRadius:aCornerRadiusIfOpaque
                                     yRadius:aCornerRadiusIfOpaque] addClip];

Here's one of the not-so-great examples:

static const CellRenderSettings checkboxSettings = {{
                                                        NSMakeSize(11, 11),  // mini
                                                        NSMakeSize(13, 13),  // small

But I can live with that :)

In some places it's also pointing out unnecessary semicolons:

@interface RadioButtonCell : NSButtonCell
@end
;

Or places where we're missing braces (this if statement was two lines before and is one line now):

  if (!topLevelWidget || !win) return YES;

Is it possible to make it enforce braces around single line ifs, so that we don't have to fix these cases manually?

I'm a bit surprised about the line length it's accepting, e.g. this line is 100 characters long (which is absolutely fine with me):

      SegmentParams params = ComputeSegmentParams(aFrame, eventState, SegmentType::eToolbarButton);

(In reply to Markus Stange [:mstange] from comment #5)

In some places it's also pointing out unnecessary semicolons:

@interface RadioButtonCell : NSButtonCell
@end
;

Do you want me to remove them?

Or places where we're missing braces (this if statement was two lines before and is one line now):

  if (!topLevelWidget || !win) return YES;

Is it possible to make it enforce braces around single line ifs, so that we don't have to fix these cases manually?
we have to use a different tool for that (clang-tidy), not sure it supports objc.

https://clang.llvm.org/extra/clang-tidy/checks/readability-braces-around-statements.html

(we can enable it at review phase if this is the case)

Do you want me to remove them?

Sure, thanks!

ignore-this-changeset

Depends on D17137

Depends on D17139

(In reply to Markus Stange [:mstange] from comment #5)

Or places where we're missing braces (this if statement was two lines before and is one line now):

  if (!topLevelWidget || !win) return YES;

Is it possible to make it enforce braces around single line ifs, so that we don't have to fix these cases manually?

You can fix them all automatically by running this command:

./mach static-analysis check -c='-*,readability-braces-around-statements' -f widget/cocoa/

This needs to be run on a Mac since it uses the build system to find files built from the widget/cocoa subdirectory so running it on Linux wouldn't really work. You can run it after this reformat too, and run ./mach clang-format -p widget/cocoa/ on the result to make sure the output is formatted properly.

Cool! Ok, then let's do that on top of these patches. Doesn't have to be this bug.

I can help here if it's needed, since I'm running on a mac.

Now that spohl has given his ok, I think these patches are ready to land. I don't mind who runs the command that Ehsan suggested; I can do it after this bug lands unless somebody else beats me to it.

Doesn't have to be this bug.

indeed, we should create a new bug for that

Nit: .mm is Objective-C++, which is roughly the common superset of Objective-C and C++; .m is plain Objective-C.

We do have a few .m files, but they seem to be mostly(?) in third-party imports.

https://hg.mozilla.org/mozilla-central/rev/d11a86413d42
https://hg.mozilla.org/mozilla-central/rev/0e3b5fe32d11
https://hg.mozilla.org/mozilla-central/rev/99f1a193599d
https://hg.mozilla.org/mozilla-central/rev/347238f5ae0a

https://hg.mozilla.org/mozilla-central/rev/a3bfdc6d05af